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ABSTRACT 



A system and method for controlling duplicate transaction 
submission in a web browser/web server environment. The 
client web browser is modified to include a process duplicate 
action select (e.g. duplicate mouse "clicks") detection. This 
process establishes a variable for an action indicating 
whether the action has been previously selected. Upon 
selection, the process tests the action variable and passes the 
transaction request if not previously submitted and returns 
an error otherwise. The server process has been augmented 
with a duplicate transaction process. The server software 
inserts a _tranid parameter into each of a plurality of 
selected pages returned to a browser for transaction process- 
ing. The server maintains a record of the last used jranid. The 
server compares a tranid returned in a user request to the 
recorded value. If previously processed, an error is returned 
to the requester. If not previously processed, the recorded 
"last transaction id" is updated and the request fulfilled. 

18 Claims, 4 Drawing Sheets 
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This processing occurs on the web server when a user 
requests a page in order to perform a transaction. For 

example, when the user clicks on a 1 want to do 
transfer 1 icon, the server will build a transfer request 
page that the user can fill in with data. Part of building 
that page is to get a new transaction id (tranid) and put 
it into 'do the transfer' URL 
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This routine executes when a user 
submits a request to the web server, it 
checks if the transaction identified by the 
tranid has been processed before. If 
not, the request is processed. If so, the 
request is not done a second time. The 
processing in the box is contained in the 
CheckDupTran function. 



03/09/2004, EAST Version: 1.4.1 



US 6,2 

1 

SYSTEM AND METHOD FOR PREVENTING 

DUPLICATE TRANSACTIONS IN AN 
INTERNET BROWSER/INTERNET SERVER 
ENVIRONMENT 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to computer processor 
implemented transaction processing systems. More 
particularly, the present invention relates to transaction 
control mechanisms for ensuring the reliability and integrity 
of transactions processed in an on-line transaction process- 
ing system. Still more particularly, the present invention 
relates to transaction processing over the Internet using 
Internet browsers and Internet servers to process on-line 
transactions. 

2. Background and Related Art 

Computer implemented transaction processing systems 
are used to manage information collected and used by 
businesses worldwide. Historically, transaction processing 
has been used by banks and airlines to handle customer 
transactions. In both of these industries, the accuracy of the 
data is a prime concern. Transaction processing systems 
have been designed to ensure that data is properly updated 
and that any failure of the system is handled in a predictable 
and recoverable manner. 

The widespread implementation of Internet technology 
has created a demand to enable consumers to directly enter 
transactions with their banks and to make reservations with 
travel companies. Implementation of client driven transac- 
tion processing systems must meet the high data integrity 
requirements consumers expect. For example, consumer use 
of an Internet banking program to transfer funds must result 
in the funds either being fully transferred into the correct 
account, or the transaction being terminated with a reported 
error. 

The problem of duplicate transaction entry is of particular 
interest The processing system must ensure that a specific 
transaction is processed once and only once. Unfortunately, 
Internet browser technology makes duplicate transaction 
entry relatively common. Internet browsers have been devel- 
oped to access and view data over the worldwide web. 
Viewing and even non-financial data entry are usually not 
harmed by duplicate transaction submissions. Financial 
transactions cannot tolerate duplicate entries. 

Duplicate transactions occur, in part, because of the 
stateless nature of browser/server applications. The server 
supplies a "web page" to the client browser for action by the 
user. The prior art servers do not retain any state information 
about the form supplied. When the browser submits the 
form, it is acted upon by the server, again without monitor- 
ing the previous state of the application. The user can cause 
the same form to be submitted a second time without the 
server detecting the duplication. 

Browser technology allows the following types of dupli- 
cate transaction entries to occur. Note that the 'enter* button 
in the following items denotes the page element that the user 
clicks on to submit a transaction. It could be a form submit 
button, a form image button, or an HREF. 

1. Enter-Back-Enter The user submits a transaction by 
clicking on an enter button. The user sees the response. Later 
the user uses the browser's 'back' button to back up into the 
previously submitted transaction and clicks on enter again 

2. Enter-Reload: Here the user submits a transaction by 
clicking on an enter button. The user sees the response and 
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then clicks on the browser 'reload* button (called 'refresh' in 
the Internet Explorer browser). Clicking the reload button 
causes the transaction to be sent to the web server a second 
time. 

5 3. Enter-Stop-Enter: The user submits a transaction by 
clicking on an enter button. While waiting for the response 
the user clicks the browser 'stop* button and the clicks the 
enter button again. Clicking the enter button the second time 
submits the transaction to the web server a second time. 

10 4. Multiple-Clicks: If a user clicks multiple times on an 
enter button, browsers may submit multiple identical trans- 
actions to the web server. The behavior of the browsers 
differs based upon which browser is used (Netscape Navi- 
gator is different than Microsoft Internet Explorer), the 

15 HTML type of the enter button, and how many clicks were 
entered. 

5. Resize: Resizing the browser window may, in some 
instances, cause the browser to reload the transaction in the 
20 browser window. 

Each of these situations results in an undesirable dupli- 
cation of transaction processing. A technical problem there- 
fore exists to prevent duplicate transaction processing in a 
browser/server environment. 

25 SUMMARY OF THE INVENTION 

The present invention solves the duplicate transaction 
processing in a browser/server environment by implement- 
ing checks on both the client browser side and server side of 
30 the transaction. Client programs running on the browser are 
be restructured to eliminate duplicate transaction submis- 
sion. Server systems are assembled to track form submission 
and to reject any duplicate forms. 

[claim language] 

It is therefore an object of the invention to eliminate 
duplicate transaction submission in a browser/server envi- 
ronment. 

It is yet another object of the invention to prevent dupli- 
40 cate processing of a transaction submitted from a browser. 
The foregoing and other objects, features and advantages 
of the invention will be apparent from the following more 
particular description of a preferred embodiment of the 
invention, as illustrated in the accompanying drawing 
45 wherein like reference numbers represent like parts of the 
invention. 

BRIEF DESCRIPTION OF THE DRAWING 

FIG. 1 is a block diagram illustrating the computer 
50 environment of the preferred embodiment of the present 
invention. 

FIG. 2 is a block diagram of a computer system according 
to the present invention. 
55 FIG. 3 is a flow chart of the process of client side 
duplicate action selection detection according to the present 
invention. 

FIG. 4 is a flow chart of the process of server side 
transaction sequence number assignment according to the 
60 present invention. 

FIG. 5 is a flow chart of the process of server side 
duplicate transaction detection according to the present 
invention. . 

65 DETAILED DESCRIPTION 

Internet applications are implemented with a client 
"browser** for user interaction and a server for application 
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processing. The client browser is graphically oriented and 
presents a graphical page of data (or screen) to the user for 
action. Data can be entered into defined fields and actions 
can be requested by clicking a pointing device, such as a 
mouse, on an action "button" or on specially defined fields 5 
on the screen. 

Internet servers process requests submitted by the brows- 
ers. Servers locate and present requested data to the user 
using forms defined according to the HyperText Markup 
Language standard (HTML.) This standard defines the con- 10 
tent of a form to be displayed by the browser and the actions 
the user will be permitted to take. The server and browser 
software need not be from the same vendor. Servers must be 
responsive to any valid HTML request from a browser and 
browsers must be responsive to server generated forms. 15 
Internet server software is marketed and sold by Netscape 
Communications Corp., IBM Corp., Microsoft Corp. and 
others. Browser software is available from these and other 
vendors. 

Application logic is typically stored in the server and 20 
executed in response to a browser request Some logic, 
however, can be downloaded to the client browser as a part 
of the form to be executed in response to a user action. This 
logic is typically coded in the JavaScript interpretive lan- 
guage developed by Netscape Communications Corp. Java- 25 
Script implements programming statements that permit cli- 
ent based action processing. 

The present invention is implemented in an Internet or 
Intranet (within one organization) system such as that shown 
in FIG. 1. Any number of client workstations with browser 
software 102, 104 are connected through a network 106 to 
an Internet server 108 running server software. The network 
106 can be any of a variety of known or to be developed 
local area network or wide area network topologies. 

The client and server computer systems will be similar to 
that illustrated generally in FIG. 2 at 200. It will have a 
processing unit 202 with one or more central processing 
units (CPUs) connected through a system bus 206 to random 
access memory 204. Network controller 208 controls data 
exchange over the network. Input/output controller 210 
manages interaction with fixed storage 212, removable 
storage 214 and user input devices such as keyboard 216, 
pointing device 218 and display monitor 220. The preferred 
embodiment employs and IBM Personal Computer as the 45 
client computer and an IBM RS/6000 workstation as the 
server computer. The invention is not limited, however, to 
any particular computer type or configuration, except as 
specified in the claims. 

The preferred embodiment solves the duplicate transac- 50 
tion problem by first eliminating duplicate transaction sub- 
mission on the client side where possible, and avoiding 
duplicate transaction processing on the server side in all 
cases. Avoiding duplicate submission is desirable even when 
duplicate processing is avoided due to the elimination of the 55 
network traffic associated with the duplicate submission. 

The client side solution is based on monitoring transaction 
submission requests and detecting duplicates. The preferred 
embodiment is implemented as a JavaScript language logi- 
cal routine to examine transaction submission. A description 60 
of client side submission processing is necessary before 
describing the preferred embodiment in detail. 

A user interacts with a server application through an 
HTML form sent to the user client browser by the server. 
The HTML language specifies certain constructs for "sub- 65 
mitting" a form or trasaction back to the server. Submission 
causes the client browser to transmit specified data back to 



the server for action. The HTML constructs (or page 
elements) typically used to cause a request to be sent to a 
server are: 

1. A FORM with an input type«submit button. 
<FORM METHOD-. . . > 

<INPUT TYPE«"submit" value="Enter"> 

2. A FORM with an input type~image button 
<FORM METHOD-. . . > 

<INPUT TYPE="image" SRC«"enter.gif '> 

3. A text HREF. 

<A HREF="pageref.html?parms=xxx"> 
Click Here To Submit Transaction. 
</A> 

4. An image HREF. 

<A HREF~"pageref .html?parms«xxx"> 

<IMG SRC«"enter.gif '> 

</A> 

If a user clicks once on any of the above types, all versions 
of Netscape Navigator and Microsoft Internet Explorer (IE) 
browsers will send a request to the specified web server. 
However, a browser's response to a user double clicking or 
triple clicking on the above types is different based on type. 

The following Table 1 shows how the Netscape Navigator 
3, Microsoft IE 3.02, and Netscape Communicator 4 brows- 
ers react when a user double clicks on the various page 
elements. 

TABLE 1 



Page 






NS 


Reference 


NS Navigator 




Communicator 


Type 


3 


MS IE 3.02 


4.01a 


TYPE - 


2 Transactions 


2 Transactions 


Usually 1 


^ 5 "submit" 








TYPE - 


Usually 1 


Usually 1 


Usually 1 


"image" 








Text HREF 


Occasionally 2 


Usually 1 


Usually 1 


Image HREF 


Ocassionally 2 


Usually 1 


Usually 1 
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The term 'usually V indicates that most of the time 
(greater than 95% in the authors testing) only a single 
transaction is sent to the web server. The term 'occasionally 
V means that the majority of the time (>50%) only a single 
transaction was sent. However, depending upon the speed at 
which the double click was done, the author could get 2 
transactions sent more ofien than the 'usually 1' case. 

The situation changes when the user triple clicks on the 
page elements. Often one would see 2 transactions submit- 
ted in this case. 

The Netscape JavaScript language includes features that 
enable JavaScript logic to be executed whenever the user 
clicks on a page element. The JavaScript event handlers get 
control whenever a user clicks on a page element. The 
present invention is directed to a novel structure of computer 
readable program code that causes an event handler to 
prevent the browser from submitting multiple transactions 
when the user clicks multiple times on a page element. 

The method for intercepting page element events differs 
between the types of page elements. The <FORM> page 
element enables an "onSubmit" Javascript event handler 
routine to be specified. The routine will be called 
"checkIfSubmitted( )" This looks like: 

<FORM METHOD-. . . onSubmit«"return 
checkIfSubmitted( )"> 

The HREF page elements enables an "onClick" Javascript 
event handler routine to be specified. 
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<A HREF-"pageref.html?parms-xxx" onclick-" return building the page for transmission to the client requests a 

checkI£Submitted( )"> tranid using a GetNewDupTran( ) function 402. This func- 

The checkIfSubmitted( ) routine is a client side Javascript tion is written in JavaScript in the preferred embodiment and 

routine provided by the page developer. Following is a maintains the assigned number sequence. A __tranid history 

checkIfSubmitted( ) Javascript event handler according to 5 is maintained for each client (user). The tranid is inserted 

the present invention- into the URL for the page and the page returned to the user 

404. 

Server side duplicate detection is performed using the 
^ — ^ CheckDupTran( ) procedure. CheckDupTran( ) compares 

<script> the tranid returned by a form to the sequence maintained at 

var submitForm-"yes"; 10 m e server a od signals an error whenever the comparison 

function chedOfSubmitted 0 { indicates duplicate submission. The two server side proce- 

if (submitForm-— yesn { j j j i_ 1 

submitForm-"no"; dures are described below. 

retum(true); } GetNewDupTran( ): This function returns a character 

else { string tranid for a new transaction. This string must be put 

rcturn(feise); } 15 mt0 a _tranid parameter in the URL. 

wscrift CheckDupTran( ): This function compares a tranid 

* obtained from the URL __tranid parameter and atomically 

compares it to the last completed transaction tranid from this 

The use of onsubmit and onClick event handlers prevents user. If the URL _tranid is greater than last completed 

duplicate transactions from being submitted on multiple 20 transaction tranid, then the function makes URL __tranid the 

clicks by the Netscape Navigator 3 and Communicator 4 last completed transaction tranid and returns a value of 0. 

browsers. Otherwise, the transaction represented by request._tranid is 

However, the Internet Explorer 3.02 browser only recog- * duplicate transaction and the function returns a non-zero 

nizes the onSubmit event handler on the FORM type=submit value. 

page reference type. IE 3.02 ignores the onSubmit event 25 ln *e Purred embodiment, the ar^ve routines are 

handler on the FORM type-image reference and the onClick ^ 45 ^ knguage tha f caa be mv ° ked ^ m 

event handler on HREF references. Fortunately, IE 3.02 does Jf aScnpt. The C language routines implement the tracking 

not frequently send multiple transactions on the page refer- °f transaction sequence number values and _ transaction 

M 4 , » states. In addition, they are used to perform the compare 

ence types on which it ignores the event handler. operations. Those skilled in the art will recognize that other 

Tte process flow for client side duplicate transaction 30 * min languages can be used to implement these 

avoidance is illustrated in FIG. 3. On entry into the form the mnctions without departing from the invention, 

variable ^submitform" is set to "yes" 302. When the user ^ servef software must insert a _ tranid in each form 

clicks a select button 304 the JavaScript checks whether the ^ {Q tfae clfcnt browser ^ _ traaid can be mserted ^ a 

variable submitForm is "yes" 306. If "yes", the submitForm hidden parameter m the forin or ^ a variable m ^ HREF 

variable is set to "no" and the request sent to the server. If 35 statementt The following demonstrates how 

submitForm is "no" the user selection is ignored and no G etNewDupTran( ) is used in server side Javascript to put 

request sent tbe _jranid parameter variable as a hidden parameter in a 

Server side duplicate transaction processing is required to <FORM>- 

ensure that duplicate transactions are not entered in spite of ,< r?^ n *yr x*r7Tuon ^»\. 

, . . , , . ,. write! <KJRM MblHUU=. . . > ); 

multiple click detection on the client. The client browser 40 v 1KmiTT r™,™ „, „ kt a x/c « * -a» 

r j i • . . . , , ... j • wnte( <INPUT TYPE- hidden NAME« _tramd 

user can cause a duplicate transaction to be submitted in IM ; Iin , _ VT _^ ^ , . . , x 

other ways. Duplicate detection on the server side is based J^f'^"^) 4 ';^ _ _ . 

on a transaction sequence number ("tranid"). ^ bVB ™°* demonstrates how GetNewDupTran( ) is 

A . , . • j - , c used to put the tranid parameter on a HREF. 

A transaction sequence number is assigned to each rorm / — 

sent to the browser for processing. The server detects any 45 wnte('<A HREF«"pageref .html?_tramd= + 

duplicate submission of a form containing a particular GetNewDupTran( )+'>'); 

transaction sequence number. The server side detection logic write('Click Here To Submit Transaction/); 

includes the following steps: write('</A>'); 

1. The tranid of the last completed transaction for the user The following demonstrates how CheckDupTran( ) is 
is saved in the web server. 50 used to check whether a transaction is a duplicate. The 

2. Pages that contain a page reference link which can following examples are based on an embodiment used by a 
submit a transaction must contain a tranid. The page must bank to process banking transactions. The example assumes 
obtain a new tranid to put into the reference link. This new a bank wants to redirect processing to a page called duper- 
tranid must be larger than the last completed transaction r.html in the event a duplicate transaction is detected, 
tranid saved in the web server. 55 if (CheckDupTran( )!-0) 

3. When a page gets control to submit a transaction, the redirect (addClient^duperr.btmr)); 

page must compare the tranid passed in the reference link to The server side bank page customizer is responsible for 

the tranid of the last completed transaction. If the tranid in getting the _jranid into the request URLs and putting the 

the reference link is greater than last completed transaction CheckDupTran( ) into the appropriate page execution paths, 

tranid, then this is a new request from the user. The tranid 60 A bank can select which transactions it wants to check for 

from the reference is put into the last completed transaction duplicates. A bank may not care if duplicate inquiry type 

tranid and the user's transaction is processed. If the tranid in transactions are sent by a user. Additionally, navigation type 

the reference is less than or equal to the last completed URLs (such as those associated with icons across the top of 

transaction tranid, then the user's request is a duplicate and a page) must not have duplicate checking done in their 

should not be processed again. 65 execution paths. (If this was done, clicking the navigation 

Obtaining a tranid for a page and adding it to the page button a second time would cause a duplicate transaction to 

follows the process illustrated in FIG. 4. The server program be detected.) 
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Server side duplicate transaction detection code must 
cause a response to be sent back to the user telling the user 
that a duplicate transaction has been detected The user needs 
to be told: 

1. What happened? 5 

2. Was the duplicate transaction processed (Was it sent to 
the bank)? 

3. What caused the problem? 

4. What can user do to avoid the problem? 

5. How does the user continue the banking session? 
Following is an example response which attempts to 

answer the above questions: 

"You submitted a transaction which is a duplicate of a 
previous transaction. The duplicate transaction has not been 
processed. You may have caused the duplicate transaction by 
one of the following actions: 15 

Using the browser "Back" button and submitting a trans- 
action. 

Using the browser "Reload" or "Refresh" button. 

Using the browser "Stop" button and submitting a trans- 
action. ' 20 

Double mouse clicking when submitting a transaction. 

You can avoid submitting duplicate transactions by using 
the navigation links provided on the banking pages. Avoid 
the use of the browser 'back', 'stop' and 'reload' buttons 
during a banking session. Click your mouse only once when 2 s 
you submit a transaction. 

You may continue your banking session by clicking a 
navigation link on this page." 

The server side processing is illustrated in FIGS. 4 and 5. 
FIG. illustrates the process flow for inserting a _tranid into ^ 
a URL. The server side process acquires a new tranid by 
invoking the GetNewDupTran( ) process 402. This tranid is 
inserted into the URL and the page returned to the user 404. 

FIG. 5 illustrates the process of duplicate detection. The 
server process starts at 502 and receives a user request with 35 
a returned page containing a __tranid 503. The server checks 
whether this __tranid has been previously processed 504 
using, for example, a routine such as CheckDupTran( ). If he 
tranid was previously processed, a "duplicate transaction" 
message is returned to the user 506 and processing termi- 4Q 
nates. If the tranid has not been processed, the tranid is saved 
as having been processed 507 and the user request in the 
transaction is processed 508. 

It will be understood from the foregoing description that 
various modifications and changes may be made in the ^ 
preferred embodiment of the present invention without 
departing from its true spirit. It is intended that this descrip- 
tion is for purposes of illustration only and should not be 
construed in a limiting sense. The scope of this invention 
should be limited only by the language of the following 
claims. 

What is claimed is: 

1. A computer implemented method for eliminating dupli- 
cate request submission from a browser to a server in a 
browser/server environment, the browser operating on a ^ 
client computer processor having client memory and client 
processing means, the method comprising the steps of: 
setting an indicator to a first state in the client memory; 
detecting a request submission at the client to send a 

request to the server; testing said indicator, and 60 
if said indicator is set to said first state, then submitting the 
request to the server, and resetting the indicator to a 
second state, 

if said indicator is set to said second state, ignoring the 
request submission and raising an error condition; 65 

thereby reducing network traffic associated with duplicate 
request submissions. 
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2. The method of claim 1, wherein said detecting step 
detects the request submission bv a pointing device means 
selection of an HTTP FORM "submit" button. 

3. The method of claim 1, wherein said detecting step 
detects the request submission by a pointing device means 
selection of an HTTP HREF selection. 

4. A computer implemented method for avoiding dupli- 
cate transaction entry in a browser client/server 
environment, the method comprising the steps of: 

detecting duplicate submission requests at said client and 
not submitting said duplicate submission requests to 
the server thereby reducing network traffic associated 
with duplicate request submissions; 

detecting duplicate submitted transactions at said server 
and rejecting said duplicates. 

5. The method of claim 4, wherein said detecting dupli- 
cate submission requests at said client comprises the steps 
of: 

setting an indicator to a first state in a client memory; 
detecting a request submission at the client to send a 

request to the server; 
testing said indicator, and 

if said indicator is set to said first state, then submitting the 
request to the server, and resetting the indicator to a 
second state, 

if said indicator is set to said second state, ignoring the 
request submission and raising an error condition. 

6. The method of claim 5, wherein said detecting dupli- 
cate submitted transactions at the server comprises the steps 
of: 

setting a unique transaction identifier for a form in a web 

page returned to said setting a unique transaction client 

to begin a transaction; 
receiving a submitted request including said form and 

returned transaction identifier; 
testing said returned transaction identifier to determine 

whether or not said transaction identifier has been 

previously returned; 
if previously returned, raising an error condition. 

7. The method of claim 6, wherein said transaction 
identifier is a numeric sequence number and wherein said 
process maintains in a memory means a value of the highest 
returned transaction identifier, and wherein said testing said 
returned transaction identifier tests said returned identifier 
against said maintained value. 

8. The method of claim 4, wherein said detecting dupli- 
cate submitted transactions at the server comprises the steps 
of: 

setting a unique transaction identifier for a form in a web 

page returned to said client to begin a transaction; 
receiving a submitted request including said form and 

returned transaction identifier; 
testing said returned transaction identifier to determine 

whether or not said transaction identifier has been 

previously returned; 
if not previously returned, performing said requested 

transaction and setting said transaction identifier as 

being returned; 
if previously returned, raising an error condition. 

9. A client computer system for avoiding duplicate trans- 
action processing in browser/server environment, the system 
comprising: 

client memory means for storing an indicator of browser 
request submission; 
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client processing means for detecting a request to submit 
a browser request to a server; 

client processing means for testing said indicator to 
determine whether said request has been previously 
submitted; 5 

client response means for raising an error condition and 
ignoring said request if said test determines the request 
was previously submitted; and 

client processing means for submitting said requested 1Q 
request and setting said indicator to indicate 
submission, if said request was not previously submit- 
ted; and 

thereby reducing network traffic associated with duplicate 
request submissions. is 

10. A web server for detecting duplicate transaction 
requests in a stateless web server environment, said web 
server having memory means and processing means, the 
system comprising: 

means for assigning a unique identifier to a form; 20 

means for sending the unique identifier in a web page to 
the browser client; 

means for receiving a browser request for a transaction 
including said unique identifier; 

means for testing said unique identifier to determine 
whether or not a transaction having said unique iden- 
tifier has been processed; 

means for processing said request of said unique identifier 
has not been previously processed, said means for 30 
processing setting an indicator that said unique identi- 
fier has been processed; and 

means for raising an error condition if said unique iden- 
tifier has been processed. 

11. The system of claim 10, wherein said means for 35 
assigning a unique identifier includes: 

means for requesting a unique identifier; and 
means for inserting said unique identifier in an form 
definition in the web page. 

12. The system of claim 11, wherein said form definition 40 
is in Hypertext Markup Protocol (HTTP) form and said 
inserting adds said unique identifier as a hidden variable. 

13. The system of claim 11, wherein said form definition 
is in Hypertext Markup Protocol (HTTP) form and said 
inserting adds said unique identifier as an HREF URL 
variable. 

14. A computer program product having a computer 
readable medium having computer program logic recorded 
thereon for avoiding duplicate transactions in a browser/ 
server computer system, said computer program product 
comprising: 

computer program product means for causing a client 
computer system to detect a browser request submis- 
sion; 
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computer program product means for causing the client 
computer system to determine whether said request has 
been previously submitted; 

computer program product means for causing the client 
computer to reject said requested submission is not 
previously submitted or returning an error if previously 
submitted; 

thereby reducing network traffic associated with duplicate 
request transmissions. 

15. The computer program product of claim 14, wherein 
said computer program product means for causing a com- 
puter to detect a browser request submission comprises: 

computer program product means for causing a computer 
to detect pointing device activation of an HTTP "sub- 
mit" field. 

16. The computer program product of claim 14, wherein 
said computer program product means for causing a com- 
puter to detect a browser request submission comprises: 

computer program product means for causing a computer 
to detect pointing device activation of an HTTP hyper- 
text link "HREF" field. 

17. The computer program product of claim 14, wherein 
said computer program product means for causing a com- 
puter to test said unique identifier comprises: 

computer program product means for causing a computer 
to store a value of said highest unique identifier for a 
client; 

computer program product means for causing a computer 
to compare a returned unique identifier to said stored 
value. 

18. The computer program product of claim 14, further 
comprising: 

computer program product means for causing a server 
computer to assign a unique identifier for a transaction 
form and embed the unique identifier in a web page sent 
from the server computer to a browser in the client 
computer; 

computer program product means for causing a server 
computer to intercept a returned form from the client 
computer having the unique identifier; 

computer program product means for causing a server 
computer to test the unique identifier to determine 
whether or not the unique identifier has been previously 
submitted; and 

computer program product means for causing a server 
computer to reject said submitted transaction if previ- 
ously submitted or to process said transaction and 
update an indicator for the unique transaction identifier 
if the unique identifier has not been previously submit- 
ted. 
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